[レポート]AWSのモダンアプリケーションに対するカオスエンジニアリング #reinvent #CON310

本記事はre:Invent 2018のセッション「CON310 - Breaking Containers: Chaos Engineering for Modern Applications on AWS」のレポートです。

概要

You may have heard of the buzzwords “chaos engineering” and “containers.” But what do they have to do with each other? In this session, we introduce chaos engineering and share a live demo of how to practice chaos engineering principles on AWS. We walk through chaos engineering practices, tools, and success metrics you can use to inject failures in order to make your systems more reliable.

スピーカー

• Adrian Cockcroft - VP Cloud Architecture Strategy, Amazon Web Services
• Ana Medina - Chaos Engineer, Gremlin

レポート

前半 - カオスエンジニアリングの背景や歴史、未来

前半はAdrian Cockcroft氏によるカオスエンジニアリングの背景や歴史、未来について。

カオスエンジニアリングの必要性について

• 何か障害が起こったときに、システムはどうすべきか？
  • 停止？
  • 機能を削って継続？
• バックアップのデータセンターはある？
  • アプリのフェイルーオーバー頻度は？
  • データセンターのフェイルーオーバー頻度は？

カオスエンジニアリングの文献について

• The Network is Reliable - An informal survey of real-world communications failures(July 23, 2014)
• Drift Into Failure
• Release It!
  • 日本語訳 - Release It! 本番用ソフトウェア製品の設計とデプロイのために
• Principles of Chaos Engineering
  • InfoQでの日本語紹介記事 - NetflixのChaos Engineeringの原則

障害の影響を和らげる実験

• どんな障害の影響があるのか？
• どんな障害緩和のメカニズムがあるのか？
• どうやったら失敗の可能性があるすべてのことを考えられるのか？

障害の分類学

• 共通言語、用語、定義などはレジリエンシに取り組む人たちのコミュニケーション障害を軽減するのに役立つ
• いくつかの用語を提案しているので、共通の用語を使うことにしよう

障害のレイヤ

• Operations
• Application
• Software stack
• Infrastructure

障害緩和のレイヤ

• アプリケーションレベルレプリケーション
• データベースレプリケーション
• ストレージレベルブロックレプリケーション

過去、現在、そして未来

• 過去
  • ディザスタリカバリ
• 現在
  • カオスエンジニアリング
• 未来
  • Resilient critical systems(回復力のある重要なシステム？)

注意

• 障害はシステムの問題であり、安全マージンの不足
  • コンポーネントエラーやヒューマンエラーの根本原因があるわけじゃない

仮説検定 - Hypothesis Testing

• 安全マージンがあると思うので、慎重にテストしてみましょう
  • プロダクション環境で
  • 問題を起こさずに

AWSメカニズム

• Amazon Aurora DB Cluster Fault Injection Queries
• IAM Region Restriction

後半 - Kubenetes Mechanisms

後半はAna Medina氏からGremlinの解説とそれを用いたデモ。
GremlinはGremlin, Inc.が提供するResilience as a Serviceを提供するプラットフォーム。

わざとカオスな状態を作り出し、回復能力を検証し、アプリケーションにダウンタイムを発生させない支援をする。

デモでは3パターンの障害注入による攻撃をし、その際にゲストブックアプリケーションの挙動がどうなるのかを披露。

1. パケットロス(20%, 50%)
2. レイテンシー(300ms)
3. コンテナのシャットダウン(Redis)

More resources on Chaos Engineering

• コミュニティ
  • https://slofile.com/slack/chaosengineering
• チュートリアル
  • https://www.gremlin.com/community/
• デモリクエスト
  • https://www.gremlin.com/demo/

さいごに

昨今、アプリケーションやインフラが高度に複雑化していっている中、サービスを運用していると開発者が想定しきれなかったような問題に遭遇することがあると思います。
サービスのダウンタイムは機会損失につながるのでできるだけ抑えたいため、異常な状態を敢えて発生させ、そこから回復できるシステムにすることは重要ですがとても難しいことです。

カオスエンジニアリングの考え方やそれを支援するツールを活かすことで、より強いサービスが作れるのではないでしょうか。